Methods, systems and program products for annotating system traces with control program information and presenting annotated system traces

ABSTRACT

The signal state that a signal of interest within a system under test has during each of a plurality of cycles of operation of the system under test is stored in a trace file. In association with the signal state, information regarding a requested access to the signal state by a control program during a particular cycle among the plurality of cycles is also stored. From the trace files a presentation is generated that presents, for at least a signal of interest within the system under test, a plurality of signal state indications, each indicating a respective state that the signal had during a one of a plurality of cycles of operation of the system under test. The presentation also indicates, in a graphically distinctive manner, at least one cycle of operation during which a control program requested access to a state of the signal, so that the influence of the control program on the state of the system under test is visually apparent.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to recording and visualizingthe operation of systems under test, and in particular, to methods,systems and program products for recording and visualizing the operationover time of a simulated system or module in which traces of particularsignals are annotated with control program information.

2. Description of the Related Art

In a typical digital design process, verifying the logical correctnessof a digital design and debugging the design (if necessary) areimportant steps of the design process performed prior to developing acircuit layout. Although it is certainly possible to test a digitaldesign by actually building the digital design, digital designs,particularly those implemented by integrated circuitry, are typicallyverified and debugged by simulating the digital design on a computer,due in part to the time and expense required for integrated circuitfabrication.

In a typical automated design process, a circuit designer enters into anelectronic computer-aided design (ECAD) system a high-level descriptionof the digital design to be simulated utilizing a hardware descriptionlanguage (HDL), such as VHDL, thus producing a digital representation ofthe various circuit blocks and their interconnections. In the digitalrepresentation, the overall circuit design is frequently divided intosmaller parts, hereinafter referred to as design entities, which areindividually designed, often by different designers, and then combinedin a hierarchical manner to create an overall model. This hierarchicaldesign technique is very useful in managing the enormous complexity ofthe overall design and facilitates error detection during simulation.

The ECAD system compiles the digital representation of the design into asimulation model having a format best suited for simulation. A simulatorthen exercises the simulation model to detect logical errors in thedigital design.

A simulator is typically a software tool that operates on the simulationmodel by applying a list of input stimuli representing inputs of thedigital system. The simulator generates a numerical representation ofthe response of the system to the input stimuli, which response may theneither be viewed on a display screen as a list of values or furtherinterpreted, often by a separate software program, and presented on thedisplay screen in graphical form. One common tool that is utilized tovisualize the operation of a simulated system is a trace viewer(sometimes referred to as an All Events Trace (AET) viewer) thatpresents the states of various signals of interest within the system asthey vary over time.

In current simulation environments, it is possible for a control programthat controls the operation of the simulator to call API functionswithin the simulator to read and alter values within the simulationmodel. The present invention appreciates that when values are modifiedwithin a model during a simulation run in this manner, a designer canbecome confused regarding the true operation of the system. For example,logic within the design under test may have driven a signal to aparticular value, while the control program has, in fact, driven thesignal of interest to a different value. Because of these differences invalues, a designer can waste significant time in debugging the tracebased upon what are thought to be errors and which are, in fact,external manipulations of system state.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention provides improvedmethods, systems and program products for recording and presenting thestate of a system under test.

In accordance with at least one embodiment of the present invention, thesignal state that a signal of interest within a system under test hasduring each of a plurality of cycles of operation of the system undertest is stored in a trace file. In association with the signal state,information regarding a requested access to the signal state by acontrol program during a particular cycle among the plurality of cyclesis also stored.

In at least one embodiment of the invention, a presentation of the tracedata within the trace file is generated. The presentation presents, forat least a signal of interest within the system under test, a pluralityof signal state indications, each indicating a respective state that thesignal had during a one of a plurality of cycles of operation of thesystem under test. The presentation also indicates, in a graphicallydistinctive manner, at least one cycle of operation during which acontrol program requested access to a state of the signal, so that theinfluence of the control program on the state of the system under testis visually apparent.

All objects, features, and advantages of the present invention willbecome apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. However, the invention, as well as apreferred mode of use, will best be understood by reference to thefollowing detailed description of an illustrative embodiment when readin conjunction with the accompanying drawings, wherein:

FIG. 1 is a high level block diagram of a data processing system thatmay be utilized to implement the present invention;

FIG. 2 is a block diagram depicting the contents of volatile systemmemory during a simulation run of a simulation model in accordance withthe present invention;

FIG. 3 is a high level logical flowchart of an exemplary process bywhich a simulator handles an API call by a simulation control program(e.g., Run Time eXecutive (RTX)) that accesses one or more signal statesin a simulation model;

FIG. 4 depicts an exemplary trace file generated by the simulator inaccordance with a preferred embodiment of the present invention;

FIG. 5A illustrates a first view of an exemplary embodiment of agraphical user interface (GUI) in which traces of signals accessed by asimulation control program are presented in a graphically distinctmanner; and

FIG. 5B depicts a second view of an exemplary embodiment of a graphicaluser interface (GUI) in which traces of signals accessed by a simulationcontrol program are presented in a graphically distinct manner.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENT

With reference now to the figures, and in particular with reference toFIG. 1, there is depicted an exemplary embodiment of a data processingsystem in accordance with the present invention. The depicted embodimentcan be realized, for example, as a workstation, server, or mainframecomputer.

As illustrated, data processing system 6 includes one or more processingnodes 8 a-8 n, which, if more than one processing node 8 is implemented,are interconnected by node interconnect 22. Processing nodes 8 a-8 n mayeach include one or more processors 10, a local interconnect 16, and asystem memory 18 that is accessed via a memory controller 17. Processors10 a-10 m are preferably (but not necessarily) identical and maycomprise a processor within the PowerPC™ line of processors availablefrom International Business Machines (IBM) Corporation of Armonk, N.Y.In addition to the registers, instruction flow logic and execution unitsutilized to execute program instructions, which are generally designatedas processor core 12, each of processors 10 a-10 m also includes anon-chip cache hierarchy 14 that is utilized to stage data to theassociated processor core 12 from system memories 18.

Each of processing nodes 8 a-8 n further includes a respective nodecontroller 20 coupled between local interconnect 16 and nodeinterconnect 22. Each node controller 20 serves as a local agent forremote processing nodes 8 by performing at least two functions. First,each node controller 20 snoops the associated local interconnect 16 andfacilitates the transmission of local communication transactions toremote processing nodes 8. Second, each node controller 20 snoopscommunication transactions on node interconnect 22 and masters relevantcommunication transactions on the associated local interconnect 16.Communication on each local interconnect 16 is controlled by an arbiter24. Arbiters 24 regulate access to local interconnects 16 based on busrequest signals generated by processors 10 and compile coherencyresponses for snooped communication transactions on local interconnects16.

Local interconnect 16 is coupled, via mezzanine bus bridge 26, to amezzanine bus 30. Mezzanine bus bridge 26 provides both a low latencypath through which processors 10 may directly access devices among I/Odevices 32 and storage devices 34 that are mapped to bus memory and/orI/O address spaces and a high bandwidth path through which I/O devices32 and storage devices 34 may access system memory 18. I/O devices 32may include, for example, a display device, a printer, a keyboard, agraphical pointer, and serial and parallel ports for connection toexternal networks or attached devices. Storage devices 34 may include,for example, optical or magnetic disks that provide non-volatile storagefor operating system, middleware and application software. Storagedevices 34 may further store data regarding the operation of a simulatedor hardware system under test, which is depicted as trace files 35.

Referring now to FIG. 2, there is illustrated a block diagram depictingexemplary contents of system memory 18 data processing system 6 of FIG.1 during the simulation of a simulation model. As shown, system memory18 includes a simulation model 200, which is a logical representation ofthe digital design to be simulated, as well as software including atesting tool (e.g., simulator 202), a simulation control program or RunTime executive (RTX) 204, and a viewer tool referred to herein as an AllEvents Trace (AET) viewer 206.

Simulator 202 loads simulation models, such as simulation model 200,into system memory 18 and interacts directly with the simulation modelsthrough its Application Programming Interfaces (APIs). For example,during a simulation run, simulator 202 resets, clocks and evaluatessimulation model 200 via various APIs 210. In addition, simulator 202reads values (e.g., signal states or latch values) at a particular pointin time in simulation model 200 utilizing GETFAC( ) API 212 and writesvalues, typically for a single simulation cycle, to simulation model 200utilizing PUTFAC( ) API 214. In the illustrated embodiment, simulator202 also provides STICKFAC( ) API 216, which persistently sets a signal(or latch) in simulation model 200 to a specified state until unset, andUNSTICKFAC( ) API 218, which unsets a persistently set signal withinsimulation model 200. Simulator 202 further stores the time-varyingstates of simulation model 200 in trace files 35 within storage devices34 so that the time-varying behavior of simulation model 200 can beanalyzed and visualized. Although simulator 202 is implemented in FIG. 2entirely in software, it will be appreciated by those skilled in the artthat the simulator can alternatively be implemented at least partiallyin hardware.

RTX 204 controls simulation of simulation models, such as simulationmodel 200. For example, RTX 204 loads test cases to apply to simulationmodel 200. In addition, RTX 204 delivers a set of API calls to the APIsprovided by simulator 202 to initialize, configure, and run simulationmodel 200. During and after simulation, RTX 204 also calls the APIsprovided by simulator 202 to check for the correctness of simulationmodel 200 by accessing various signals and latches within simulationmodel 200.

AET viewer 206 supports cycle-based analysis of simulation model 200 bypresenting the states of signals (or latches) of interest withinsimulation model 200 as a function of simulation clock cycles. In orderto present this data, AET viewer 206 accesses trace files 35 withinstorage devices 34 and presents the trace data contained therein in aselected format, for example, in a tabular format or graphical format ona hardcopy printout or in a graphical user interface (GUI) presentation.As is appreciated by those skilled in the art, the ability to analyzeand visualize the states of time-varying signals in this manner providesa powerful tool for debugging the system under test represented bysimulation model 200.

As discussed briefly above, the present invention recognizes that theutility of AET viewer 206 in presenting and debugging the time-varyingstate of a system under test is enhanced if access to and manipulationof the system under test (e.g., simulation model 200) by RTX 204 is madeexplicit in the presentation of the trace data. In this manner, changesin system state forced by RTX 204 can be more readily distinguished fromerrors within simulation model 200. In order to permit AET viewer 206 topresent accesses to simulation model 200 by RTX 204, simulator 202preferably annotates trace files 35 with information regarding API callsby RTX 204, as described in detail below.

With reference now to FIG. 3, there is illustrated a high level logicalflowchart of an exemplary process by which simulator 202 handles an APIcall by RTX 204 in accordance with a preferred embodiment of the presentinvention. As shown, the process begins at block 300 and thereafterproceeds to block 302, which illustrates simulator 202 receiving an APIcall from a routine within RTX 204 that requests an access to a signal(or latch) state within simulation model 200. For example, as shown inFIG. 2, the RTX routine Write_Signal 230 may issue a call to PUTFAC( )API 214, the RTX routine Read_Signal 232 may issue a call to GETFAC( )API 212, or the RTX routine Pin_Signal 234 may issue a call to STICKFAC() API 216 or UNSTICKFAC( ) API 218. As indicated at block 302 of FIG. 3,each of these API calls preferably includes in its parameter list thename of the calling routine (e.g., Write_Signal), a signal (or latch)name, and if a PUT-type access, the signal (or latch) state to which thespecified signal or latch is to be forced.

Following block 302, the process proceeds to block 304, which depictssimulator 202 performing the indicated access to simulation model 200.For example, an API call to GETFAC( ) API 212 causes GETFAC( ) API 212to read the state of the selected signal from simulation model 200, andan API call to PUTFAC( ) API 214 causes PUTFAC( ) API 214 to set thespecified signal within simulation model 200 to the indicated state forthe given simulation cycle. Next, as shown at block 306, simulator 202stores in a trace file 35 information regarding the current simulationcycle. For example, as depicted within block 306, simulator 202 storesin association with the current simulation cycle, the type of API call(e.g., PUT or GET), the name of the calling routine within RTX 204, thesignal name of the signal accessed in response to the API call, and thesignal state. As shown at block 308, for PUT-type accesses that modify asignal state within simulation model 200, simulator 202 may optionallystore the unmodified state of the signal and, again optionally, afurther indication of whether or not the signal state specified in thePUT-type API call modified the signal state. If multiple PUT-typeaccesses are made to a particular signal in the same cycle, states areapplied to the signal in the order the PUT-type API calls are made, sothat the final signal state is that specified by the last PUT-type APIcall prior to cycling simulation model 200.

Following block 308, the process proceeds to block 310, which depictssimulator 202 providing a response, if any, to the calling RTX routine.For example, if simulator 202 received an API call to GETFAC( ) API 212from Read_Signal routine 232, simulator 202 returns to Read_Signalroutine 232 the state of the specified signal. Simulator 200 may notprovide responses to other RTX calling routines or may simply provide acompletion response. Following block 310, the process terminates atblock 312.

Referring now to FIG. 4, there is depicted a logical representation ofan exemplary trace file 35 created by simulator 202 in accordance withthe present invention. Those skilled in the art will appreciate that thedepicted data structures are merely exemplary, and that a wide varietyof other formats for trace files 35 may be employed. For example, inother embodiments a more compact trace file may be obtained by recordingonly changes to signal states or by selectively storing onlyuser-specified accesses to the simulation model (e.g., only GETs or onlyPUTs).

As shown, exemplary trace file 35 is logically arranged as a series oftables 400 a-400 n, which each stores trace data for a respective signalof interest over a simulation run. Each table 400 logically containsmultiple rows each corresponding to a particular simulation cycle andmultiple columns for storing trace data associated with the cycles. Inthe depicted embodiment, the columns in each table 400 include a signalstate column 404 for storing the signal state during the indicatedsimulation cycle, a calling routine name column 406 for storing the nameof an RTX calling routine, if any, accessing the signal during theindicated simulation cycle, a call type column 408 for storing anindication of the type (e.g., GET or PUT) of the RTX calling routine,and an unmodified signal state column 410 for storing the unmodifiedstate of the signal if a PUT-type routine requests access to thesimulation model 200.

Utilizing the above information within trace files 35, AET viewer 206can present a tabular or graphical representation of the trace data thatindicates accesses to simulation model 200 in response to API calls byRTX 204 in a graphically distinctive manner. In one preferred embodimentof the present invention, AET viewer 206 presents the trace data ingraphical form (e.g., within a hardcopy printout or on a displaydevice), and accesses to simulation model 200 in response to API callsby RTX 204 are depicted in a graphically distinctive manner.

With reference now to FIG. 5A, there is illustrated a first view of anexemplary embodiment of a graphical user interface (GUI) 500 generatedby AET viewer 206 within the display of a display device among I/Odevices 32 based upon trace data within a trace file 35. In accordancewith the present invention, graphical representations of signal statesaccessed by a simulation control program, such as an RTX, are presentedwithin GUI 500 in a graphically distinctive manner.

As shown, GUI 500 includes conventional GUI components, such as window502, control buttons 504, pull down menus 506, and a cursor 508controlled by a user input device, such as a mouse. Although notillustrated, GUI 500 may, of course, include other additionalconventional or non-conventional GUI features, such as tool bars, scrollbars, etc. to facilitate user interaction with and manipulation of GUI500.

Window 502 further contains a frame 510 within which graphicalrepresentations of time-varying signals of interest are presented. Forexample, GUI 500 presents within frame 510 graphical signalrepresentations 520 a, 520 b and 520 c of the states of signals X, Y andZ, respectively, of simulation model 200 as a function of simulationcycles. As shown, each graphical signal representation 520 comprises aplurality of segments, each representing the state of the associatedsignal during one or more simulation cycles. The presentation ofgraphical signal representations 520 a-520 c can readily be generated,for example, from signal state columns 404 of the tables 400 for thesignals of interest.

In order for a user to be able to visually distinguish simulation cyclesin which RTX 204 made API calls to access signal states, GUI 500presents signal segments accessed in response to an RTX API call in agraphically distinct manner. The distinctive display may incorporateline style, line weight, color, reverse video, underlining, text or anyother visually discernable parameter. Further, the display parametersmay be user-selected, for example, by making appropriate selectionswithin the “View” pull-down menu utilizing cursor 508. In the depictedembodiment, GUI 500 presents segments 522 a, 522 b, and 522 ccorresponding to signal states read from simulation model 200 by GETFAC() API 212 in response to an RTX API call utilizing underlining. In thismanner, a user can determine at a glance that RTX 204 called GETFAC( )API 212 to read the state of signal X during simulation cycle 0222 andto read the state of signal Y during simulation cycles 0223 and 0229.

GUI 500 of AET viewer 206 similarly presents segments 524 a, 524 bcorresponding to signal states forced on simulation model 200 by PUTFAC() API 214 or STICKFAC( ) API 216 in a graphical distinctive manner. Inthe illustrated embodiment, such signal states are presented utilizingdashed lines. Thus, the user can readily determine that RTX 204 forced alogic high state on signal X during simulation cycle 227 and forced alogic high state on signal X during simulation cycles 0219 through 0223.

As will be appreciated, AET viewer 206 can determine which segments topresent in a graphically distinctive manner and which graphicallydistinctive characteristic to apply to such segments based upon thetrace data contained in columns 408 of tables 400.

GUI 500 also advantageously provides the user with information regardingwhich RTX routine issued each API call. In the depicted embodiment, thisinformation is presented as flyover text in response to the userpositioning cursor 508 within a bounding region surrounding a signalsegment representing a GET or PUT-type access to simulation model 200.For example, GUI 500 presents flyover text 526 in response to cursor 508being positioned adjacent segment 524 a to indicate that a call toPUTFAC( ) API 214 was made by Write_Signal routine 230 of RTX 204.Similarly, in the second view of GUI 500 shown in FIG. 5B, GUI 500presents flyover text 528 in response to cursor 508 being positionedadjacent segment 524 b to indicate that a call to STICKFAC( ) API 216was made by Pin_Signal routine 234 of RTX 204. Advantageously, forPUT-type accesses made by PUTFAC( ) API 214 and STICKFAC( ) API 216, theflyover text may further indicate the state of the signal would have hadabsent the API call (e.g., “0” or “1”). The RTX routine names andunmodified signal values may be obtained by AET viewer 206, for example,from the trace data within columns 406 and 410 of tables 400. In thecase in which multiple PUTs and/or GETs to a signal are performed in asingle simulation cycle, the signal value and routine name that arepresented within GUI 500 are the last to be recorded in the record for athe simulation cycle.

As has been described, the present invention supports the annotation oftrace data with indications of accesses to the system under test inresponse to requests by a control program. The present invention furthersupports the presentation of the annotated trace data so that signalstates accessed by the control program are presented in a graphicallydistinctive manner.

While the invention has been particularly shown as described withreference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, it will be appreciated that although the present inventionhas been described with respect to one preferred embodiment in which asoftware simulator is employed, the inventive concepts disclosed hereinare equally applicable to the debugging and presentation of system stateof systems under test by a hardware simulator. In addition, thoseskilled in the art will appreciate that the present invention isapplicable not only to cycle-based simulators, but also to event-drivensimulators.

Furthermore, although aspects of the present invention have beendescribed with respect to a computer system executing software thatdirects the functions of the present invention, it should be understoodthat present invention may alternatively be implemented as a programproduct for use with a data processing system. Programs defining thefunctions of the present invention can be delivered to a data processingsystem via a variety of signal-bearing media, which include, withoutlimitation, non-rewritable storage media (e.g., CD-ROM), rewritablestorage media (e.g., a floppy diskette or hard disk drive), andcommunication media, such as digital and analog networks. It should beunderstood, therefore, that such signal-bearing media, when carrying orencoding computer readable instructions that direct the functions of thepresent invention, represent alternative embodiments of the presentinvention.

1. A method of recording the operation of a system under test, saidmethod comprising: in a trace file within a storage device, storing asignal state of a signal of interest within the system under test duringeach of a plurality of cycles of operation of the system under test; andstoring, in the trace file in association with the signal state,information regarding a requested access to said signal state by acontrol program during a particular cycle among said plurality ofcycles.
 2. The method of claim 1, wherein storing information regardinga requested access comprises: storing an identifier of a control programrouting that requested said access.
 3. The method of claim 1, whereinstoring information regarding a requested access comprises: storing anindication of whether said access is a GET-type access or a PUT-typeaccess.
 4. The method of claim 1, wherein storing information regardinga requested access comprises: storing an indication of a state that saidparticular signal would have had in absence of said access.
 5. Themethod of claim 1, wherein: said system under test is a simulationmodel; and said step of storing information regarding said requestedaccess comprises a simulator storing information regarding a requestedaccess by a simulation control program.
 6. The method of claim 1, andfurther comprising: presenting, for the signal of interest within thesystem under test, a plurality of signal state indications eachindicating a respective state that said signal had during a one of aplurality of cycles of operation of the system under test; andindicating, in a graphically distinctive manner, at least one cycle ofoperation during which a control program requested access to a state ofsaid signal.
 7. A method of presenting a time-varying state of a systemunder test, said method comprising: presenting, for at least a signal ofinterest within the system under test, a plurality of signal stateindications each indicating a respective state that said signal hadduring a one of a plurality of cycles of operation of the system undertest; and indicating, in a graphically distinctive manner, at least onecycle of operation during which a control program requested access to astate of said signal.
 8. The method of claim 7, wherein presenting aplurality of signal state indications comprises: presenting a graphicalsignal representation including a plurality of segments each indicatinga particular signal state.
 9. The method of claim 8, wherein saidindicating comprises presenting one or more of said plurality ofsegments in a graphically distinctive manner.
 10. The method of claim 7,and further comprising: presenting, in association with said cycle ofoperation in which the control program requested access to the state ofsaid signal, an identifier of a calling routine within said controlprogram.
 11. The method of claim 7, and further comprising: presenting,in association with said cycle of operation in which the control programrequested access to the state of said signal, a signal state said signalwould have had absent said access.
 12. A data processing system forrecording the operation of a system under test, said data processingsystem comprising: a processor; and data storage coupled to saidprocessor and containing a testing tool executable by said processor tocause said data processing system to store, in a trace file within thedata storage, a signal state of a signal of interest within the systemunder test during each of a plurality of cycles of operation of thesystem under test and to store, in the trace file in association withthe signal state, information regarding a requested access to saidsignal state by a control program during a particular cycle among saidplurality of cycles.
 13. The data processing system of claim 12, whereinsaid information comprises an identifier of a control program routingthat requested said access.
 14. The data processing system of claim 12,wherein said information comprises an indication of whether said accessis a GET-type access or a PUT-type access.
 15. The data processingsystem of claim 12, wherein said information comprises an indication ofa state that said particular signal would have had in absence of saidaccess.
 16. The data processing system of claim 12, wherein: said systemunder test is a simulation model; said control program comprises asimulation control program; and said testing tool comprises a simulator.17. The data processing system of claim 12, and further comprising: aviewer tool within the data storage and executable by said dataprocessing system to cause the data processing system to generate apresentation that presents, for the signal of interest within the systemunder test, a plurality of signal state indications each indicating arespective state that said signal had during a one of a plurality ofcycles of operation of the system under test and that indicates, in agraphically distinctive manner, at least one cycle of operation duringwhich a control program requested access to a state of said signal. 18.A data processing system for generating a presentation of a time-varyingstate of a system under test within a presentation device, said dataprocessing system comprising: a processor; and data storage coupled tosaid processor and containing a viewer tool executable by said processorto generate a presentation that presents, for at least a signal ofinterest within the system under test, a plurality of signal stateindications each indicating a respective state that said signal hadduring a one of a plurality of cycles of operation of the system undertest and that indicates, in a graphically distinctive manner, at leastone cycle of operation during which a control program requested accessto a state of said signal.
 19. The data processing system of claim 18,wherein said plurality of signal state indications comprises a graphicalsignal representation including a plurality of segments each indicatinga particular signal state.
 20. The data processing system of claim 19,wherein said presentation indicates said at least one cycle of operationby presenting one or more of said plurality of segments in a graphicallydistinctive manner.
 21. The data processing system of claim 18, whereinsaid presentation of said viewer tool further presents, in associationwith said cycle of operation in which the control program requestedaccess to the state of said signal, an identifier of a calling routinewithin said control program.
 22. The data processing system of claim 18,wherein said presentation of said viewer tool further presents, inassociation with said cycle of operation in which the control programrequested access to the state of said signal, a signal state said signalwould have had absent said access.
 23. The data processing system ofclaim 18, and further comprising the presentation device coupled to saidprocessor.
 24. A program product for recording the operation of a systemunder test, said program product comprising: a computer-usable medium;and a testing tool within said computer-usable medium and executable bya data processing system to cause said data processing system to store,in a trace file within the data storage, a signal state of a signal ofinterest within the system under test during each of a plurality ofcycles of operation of the system under test and to store, in the tracefile in association with the signal state, information regarding arequested access to said signal state by a control program during aparticular cycle among said plurality of cycles.
 25. The program productof claim 24, wherein said information comprises an identifier of acontrol program routing that requested said access.
 26. The programproduct of claim 24, wherein said information comprises an indication ofwhether said access is a GET-type access or a PUT-type access.
 27. Theprogram product of claim 24, wherein said information comprises anindication of a state that said particular signal would have had inabsence of said access.
 28. The program product of claim 24, wherein:said system under test is a simulation model; said control programcomprises a simulation control program; and said testing tool comprisesa simulator.
 29. The program product of claim 24, and furthercomprising: a viewer tool within the computer-usable medium andexecutable by a data processing system to cause the data processingsystem to generate a presentation that presents, for the signal ofinterest within the system under test, a plurality of signal stateindications each indicating a respective state that said signal hadduring a one of a plurality of cycles of operation of the system undertest and that indicates, in a graphically distinctive manner, at leastone cycle of operation during which a control program requested accessto a state of said signal.
 30. A program product for generating apresentation of a time-varying state of a system under test within apresentation device, said program product comprising: a computer-usablemedium; and a viewer tool within said computer-usable medium andexecutable by a data processing system to generate a presentation thatpresents, for at least a signal of interest within the system undertest, a plurality of signal state indications each indicating arespective state that said signal had during a one of a plurality ofcycles of operation of the system under test and that indicates, in agraphically distinctive manner, at least one cycle of operation duringwhich a control program requested access to a state of said signal. 31.The program product of claim 30, wherein said plurality of signal stateindications comprises a graphical signal representation including aplurality of segments each indicating a particular signal state.
 32. Theprogram product of claim 31, wherein said presentation indicates said atleast one cycle of operation by presenting one or more of said pluralityof segments in a graphically distinctive manner.
 33. The program productof claim 30, wherein said presentation of said viewer tool furtherpresents, in association with said cycle of operation in which thecontrol program requested access to the state of said signal, anidentifier of a calling routine within said control program.
 34. Theprogram product of claim 30, wherein said presentation of said viewertool further presents, in association with said cycle of operation inwhich the control program requested access to the state of said signal,a signal state said signal would have had absent said access.